1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer program product for providing a piggy-backed key exchange protocol. This protocol is used between a client and server to establish security parameters that are used to exchange data in a secure manner. By piggy-backing the key exchange onto other messages, the overhead associated with setting up a secure browser connection is reduced.
2. Description of the Related Art
Traditionally, complex distributed applications have been designed around the client/server paradigm, where the application logic is split into two integral parts. One of the parts provides the client functionality, and the other provides the server functions. Each of the parts is then installed on the respective hardware. Such an architecture has the fundamental drawback that the application usually must be tailored around a particular user device and vice versa: the application must function on the particular hardware and software profile of the intended user device, and the user device must meet the application requirements in terms of form-factor, processor requirements, storage capabilities, etc. This coupling leads to the implementation of the client functionality being fundamentally tied to a single type or class of end-user device. The client implementation typically must be modified in order to operate on different devices or operating system platforms, and separate versions must be provided to address the inherent differences in the devices and platforms. This leads to increased complexity and expense for application development and testing, distribution and support, etc. Because of the proliferation in client device types, it is becoming increasingly demanding to provide applications that reliably meet the constraints imposed by the different device types. This proliferation also creates a greater burden on end users who must similarly obtain and manage different versions of their application software, one for each type of device.
In the face of these challenges, there is a clear trend toward delivering applications to users in a form that is accessible via a more standard infrastructure that is available on most hardware and operating system platforms. One type of standard infrastructure is the browser. (Note that the browser implementation itself is generally non-portable, but the intent is to have the browser represent the only platform-specific code that developers write and that end users must deploy.) Within this standard infrastructure, application-specific content may be retrieved and presented to the user. Moreover, application-specific logic may be executed within an appropriate scripting environment provided on the client side by most browsers, including Netscape Navigator® and Internet Explorer. (“Netscape Navigator” is a registered trademark of Netscape Communications Corporation.) On some devices, the scripting environment may be separate from the browser, and may support richer (though still portable) application logic such as those applications written in the Java programming language. (“Java” is a trademark of Sun Microsystems, Inc.)
The tradeoff that comes from making the client infrastructure standard, however, is that it is also generic. That is, while the infrastructure is not written for the needs of a particular client application, it is able to act as the client for a wide range of applications. In this generic client environment, the problem of implementing each application shifts primarily toward the server side. (Hereinafter, the term “browser” will be used to refer to the generic client software, including the associated scripting and application environment(s).) This, in turn, somewhat complicates the tasks that must be implemented in the server software, as the server software must adapt the content to match the capabilities of the particular browser executing on the client. Alternatively, the burden may be shifted to one or more computers in the delivery chain between the client and server. In particular, a variety of transcoders and gateways can be envisaged in this delivery chain. Each of these transcoders and gateways may potentially have knowledge of a target client device's particularities, which the transcoder or gateway can then use to adjust data generated by a server application that is being delivered to this client. The Wireless Application Protocol, or “WAP,” is an example of an application architecture which may employ this type of multiple transcoder and multiple gateway environment.
In such an environment where data is being transmitted between a client and server while passing through intermediate transcoders or gateways, data security is often a key concern. A client may need to send data to the server that is considered security-sensitive by the client or the server, such as when a person's credit card information is transmitted through a network for use by an electronic shopping application executing on the server. In addition, the content dispatched from the server to the client is often considered security-sensitive. A simple example of this situation is the same electronic shopping application just discussed, where the server may transmit an order confirmation to the client that includes the client's credit card information. Many other security-sensitive transmissions exist, such as those that occur when using electronic banking, online stock trading, online bill presentment and payment, etc. The problems that may ensue when sensitive data is exposed to an unintended recipient, such as a computer hacker, can be quite serious. While gateways, and transcoders in particular, may be designed to modify the application content in legitimate ways when forwarding it through the delivery chain, sensitive content at the same time must not be disclosed to such intermediaries. (U.S. patent application Ser. No. 09/352,534, now U.S. Pat. No. 6,763,460, which is titled “Method for Transmitting Information Data from a Sender to a Receiver via a Transcoder, Method of Transcoding Information Data, Method for Receiving Transcoded Information Data, Sender, Transcoder and Receiver” and is assigned to the sane assignee, defines a novel technique for use in such an environment where the security-sensitive portions of a Hypertext Markup Language, or HTML, document are encrypted while leaving the remaining portions in plain text.)
A number of security protocols have been developed for use in client/server and other networking environments. Examples include the SSL (Secure Sockets Layer), TLS (Transport Layer Security), and WTLS (Wireless Transport Layer Security) protocols. (TLS is being defined by the Internet Engineering Task Force as a follow-on replacement for SSL, and WTLS is being developed by the WAP Forum as a security protocol optimized for the mobile computing environment.) These protocols all share the characteristic of encrypting all data transmitted through a network connection or communication session, thereby preventing an intermediary, such as a transcoder, from inspecting and/or modifying any of the data being exchanged. Consequently, these transport-based security protocols are ineffective in environments having transcoders and gateways that must legitimately modify and therefore inspect some non-security-sensitive sections of the data stream.
To enable intermediaries to perform legitimate content modifications, end-to-end security in a complex delivery chain such as that described above must be provided at the application layer (referred to equivalently as the “application level”) of the client and server. This means that security-related functions such as encryption, decryption, and authentication are performed under control of the application software, as only the application is able to distinguish between content that can be transmitted in plaintext (i.e. can be exposed to and acted upon by intermediaries) and content that is security sensitive and must be protected end-to-end (i.e. cannot be exposed to or acted upon by intermediaries). When application-level security is employed, the application invokes the services of specialized security software or tools to perform encryption, decryption, and authentication. Once the sensitive data has been encrypted at the application level, lower-layer functions of the system (such as the communications protocol stack, which is responsible for packetizing the content into messages, transmitting those messages to the destination, and re-assembling those messages into the original content) are unable to decrypt and modify that data. More importantly, such sensitive data also cannot be decrypted by the intermediate computers in the delivery chain, since these computers neither execute the application-level code shared by the client and server nor have access to the security keys and credentials used to encrypt the data. Similarly, the raw data corresponding to the encrypted content is not visible to hackers who might try to intercept it.
While an end-to-end security session established at the application layer provides advantageous security protection in the manner described above (i.e., allowing the secure exchange of information between application endpoints without being subject to decryption and/or modification by network intermediaries or hackers), application-layer security also imposes several drawbacks. First, a number of message exchanges may occur before a suitable set of parameters can be agreed upon. For example, security protocols require a key exchange phase where the client and server exchange and negotiate parameters such as the cipher suite and session key to be used during this security session. While this may be of little consequence when using high bandwidth, relatively inexpensive connections such as those provided in local area networks or the wired Internet, each message transmitted in a wireless environment such as SMS (Short Message Services) or USSD (Unstructured Supplementary Services Data) carries a rather high cost to the user. Thus, establishing the secure application-level session can be an expensive operation. Second, the message exchanges used to establish secure sessions are not easily encapsulated within existing application-layer protocols. These protocols consist of an already-defined set of primitives for communication between the client and server applications, and it is usually impossible to introduce the additional protocol primitives required for an application-level security parameter negotiation.
Accordingly, what is needed is a technique for establishing and maintaining end-to-end security sessions at the application level while maintaining the integrity of any application-layer communications protocol and without adding undue amounts of communications and message exchanges.